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ABSTRACT 


This  report  gives  users  of  the  DTNSRDC  computers  an  overview 
of  the  principles  of  software  engineering  and  describes  various 
software  engineering  techniques  that  users  with  either  large  or 
small  applications  would  find  beneficial. 


BACKGROUND  &  DEFINITION 

The  term  "Software  Engineering"  was  coined  during  the  late 
1960's  at  a  NATO  Science  Committee  conference.  Since  then,  many 
articles  and  books  have  been  published  in  an  attempt  to  define 
this  approach  to  producing  and  managing  software.  T’hese  defini¬ 
tions  are  based  on  the  types  of  theoretical  foundations  and  prac¬ 
tical  disciplines  found  in  the  more  common  branches  of  engineer¬ 
ing. 

"Software  engineering  is  a  discipline,  rather 
than  a  technology.  While  it  uses  technology, 
it  also  encompasses  the  methods  and  practices 
of  people  who  produce  software.  Many  of  the 
problems  with  today's  software,  viz.  its  high 
cost,  long  delivery  time,  and  unreliability, 
have  been  attributed  to  inadequate  software 
engineering" . [1] 


"Software  engineering  is  not  just  a  collec¬ 
tion  of  tools  and  techniques,  it  is  ...  a 
full-fledged  engineering  discipl ine. . ." . [2] 


"...the  establishment  and  use  of  sound 
engineering  principles  (methods)  in  order  to 
obtain  economically  software  that  is  reliable 
and  works  on  real  machines." [3] 

These  authors  and  others  have  recognized  the  basic  need  of 
any  group  responsible  for  producing  or  managing  software  to 
establish  a  discipline,  technique,  or  method  by  which  reliable, 
flexible,  and  timely  software  is  developed,  tested,  and  main- 
tai ned. 


PURPOSE 


The  decrease  in  hardware  costs  and  increase  in  software 
costs  in  recent  years,  combined  with  the  growing  Jag  between  com¬ 
puter  hardware  development  and  software  technology,  have  produced 
what  many  experts  have  called  the  first  part  of  a  "software 
crisis".  This  continuing  trend  is  reflected  in  Figure  1. 


Year 

Figure  1.  Hardware/Software  Tost  Trends 
(Source  of  Data;  Boehm  [4]) 

As  the  chart  illustrates,  during  the  last  25  years,  both  the  cost 
of  raw  computing  power  and  the  per  unit  cost  of  memory  and 
storaqe  have  been  dramatically  reduced.  At  the  same  time,  the 
cost  of  producing  the  additional  software  necessary  to  take 
advantage  of  this  increasing  computer  capacity  continues  to  rise. 

Deficiencies  in  the  areas  of  talent  and  effective 
tools/methods  make  up  the  second  part  of  the  "software  crisis". 
There  is  a  continuing  shortage  of  talent  in  the  software  areas  of 
design,  development,  and  management.  This  skilled  manpower  shor¬ 
tage  has  often  caused  projects  to  be  carried  out  by  a  mix  of  peo¬ 
ple  with  differing  types  of  data  processing  skills  and  experi¬ 
ence.  Also,  few  software  projects  have  been  completed  within  the 
constraints  of  original  cost,  schedule,  and  performance  specifi¬ 
cations.  A  large  part  of  the  cost  overrun  problem  is  due  to  a 
growing  lag  in  the  development  of  software  tools  and  methods  to 
manage  the  growing  complexity  of  sophisticated  software  systems. 
Lack  of  planning  and  hardware  problems  also  contribute  to  cost 
overruns. 


Additionally,  when  software  evolves  in  a  continually  chang¬ 
ing  R&D  environment,  it  is  especially  important  to  attempt  to 
"extend  code  life  expectancy  by  stressing  designs  with  built-in 
flexibility  and  re-utilization  potentials." [5] 

Software  management  can  be  defined  as  "the  technical  and 
management  control  throughout  the  life  cycle  of  all  software  that 
supports  an  organization's  mission  and  objectives." [6]  This 
management  is  the  responsibility  of  the  computer  user  organiza¬ 
tion.  It  serves  to  establish  accountability  for  project  deci¬ 
sions  and  objectives  and  also  provides  upper  management  with  vis- 
able  measures  of  progress  toward  desired  goals.  Good  software 
management,  initiated  at  the  beginning  of  a  project's  life  cycle, 
tends  to  produce  a  higher  quality  software  product.  High-quality 
software  can  be  defined  as  having  the  following  characteristics: 


1.  Reliability  4.  Portability 

2.  Clarity  5.  Eff ici ency /Economy 

3.  Maintainability  6.  Testability 


Many  authorities  agree  that  a  software  engineering  approach 
will  alleviate  many  software  development  problems. 

"An  engineering  effort  involves  a  specific 
sequence  of  steps  beginning  with  a  general 
plan,  proceeding  through  detailed  design,  and 
concluding  with  implementation  of  the 
design. "  [7] 

When  applied  to  a  software  design  effort,  it  assures  the  likeli¬ 
hood  that  the  final,  product  will  better  resemble  the  system 
design,  while  allowing  individual  creativity  and  innovation. 


CONCEPTS  AND  SUGGESTED  TECHNIQUES 

'’’he  following  section  describes  some  software  engineering 
techniques  that  may  be  used  to  achieve  the  aforementioned  goals 
of  high-quality,  economical,  and  timely  software  in  the  areas  of 
software  development 


PROJECT  DEVELOPMENT  TEAM  APPROACH 

A  project  development  team  is  often  the  basic  organization 
used  to  improve  manageability  and  productivity  of  software  pro¬ 
jects.  This  approach  allows  management  to  assemble  the  necessary 


mixture  of  various  skills  from  the  talent  available  and  is  an 
effective  method  for  overcoming  the  talent  shortage.  Addition¬ 
ally,  the  project  team  approach  allows  for  peer  review,  better 
dissemination  of  technical  and  status  information,  and  better 
back-up  of  knowledgeable  personnel.  This  approach  also  allows  for 
a  certain  amount  of  on-the-job  training  when  a  team  consists  of 
both  trainee  and  journeyman  personnel.  The  optimum  design  group 
is  made  up  of  two-man  teams,  each  working  on  a  module  or  project 
element.  Figure  2  illustrates  a  suggested  organizational  struc¬ 
ture  for  a  large  project. 
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Figure  2.  Project  Development  Group  Organization 
(Source  of  Data;  Jensen  [2]) 

At  each  level,  the  leader  is  technically  involved.  The  short 
communication  paths  ensure  good  communication  between  the  project 
team  members.  Periodic  design  walkthroughs  with  the  other  ele¬ 
ments  ensure  correct  interfacing.  This  structure  may  be  scaled- 
down  for  smaller  projects,  eventually  to  as  sma1!  as  two  people, 
with  the  more  experienced  person  being  the  proiect  leader  as  well 
as  part  of  the  design  team. 

The  advantages  of  this  approach  are: 


the  more  effective  use  of  human  resources 


-  a  better  design  due  to  continuous  walkthroughs 

-  insurance  against  loss  of  personnel 

-  an  improved  training  atmosphere  for  "junior"  programmers 


DOCUMENTATION 

Documentation  is  a  key  element  at  all  levels  of  project, 
development.  System  requirement  documents  and  technical  reviews 
serve  as  quality  controls  for  the  Definition  and  Initiation 
phases  of  a  project.  An  on-going  Project  Record,  initiated  at 
project,  conception,  should  continue  during  the  system  life,  "’he 
Project  Record  is  an  open,  official  record  of  the  major  decisions 
and  pertinent  documents  and  specifications.  Note  that  the  Pro¬ 
ject  Record  is  not  a  Technical  Notebook,  which  is  also  an  effec¬ 
tive  control  method  used  as  an  informal  medium  for  exchanging 
tentative  proposals  among  designers  and  programmers.  Design 
Specifications ,  specifying  the  input  and  output  of  each  process 
and  the  data  flow  interconnections,  and  a  formal  Test  Plan, 
detailing  the  testing  schedule  and  range  of  test  cases,  are  two 
other  recommended  documents. 


STRUCTURED  PROGRAMMING 

Structured  programming  techniques,  a  concept  that  encom¬ 
passes  programming  team  management,  design  methods,  and  program¬ 
ming  technology,  may  also  be  used.  Of  the  many  definitions  of 
this  basic,  scientific  methodology  cited  in  software  literature, 
perhaps  the  most  preferred  is: 

""Structured  programming”  is  the  formulation 
of  programs  as  hierarchical,  nested  struc¬ 
tures  of  statements  and  objects  of  computa¬ 
tion."  [  8  ] 

Structured  programming  is  often  referred  to  as  "modular"  or 
"top-down"  programming.  'the  many  methods  and  programming  tech¬ 
niques  vary  widelv,  but  all  have  as  their  objective  a  more  organ- 
i zed  and  more  manageable  software  product  achieved  by  subdividing 
a  complex  problem  into  its  basic  elements.  Some  structured  pro¬ 
gramming  methodologies  are  listed  in  Figure  3.  Complete  descrip¬ 
tions  of  the  individual  approaches  can  be  found  in  the  refer¬ 
ences. 


This  partitioning  technique  allows  the  creation  of  well- 
defined,  functional  modules  and  focuses  attention  on  interfaces 
among  modular  entities.  Another  important  benefit  is  the  iden¬ 
tification  of  distinct,  independant  software  development  tasks. 
The  project  leader  is  thereby  able  to  assign  design  responsibil¬ 
ity  for  a  new  process  or  procedure  to  a  team,  which  "proceeds  in 
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NAME 

APPROACH 

APPLICATIONS 

Top-Down 
Design 
[9]  [10] 

Based  upon  decomposition 
by  trial  and  error 

Data  processing  and 
and  algorithmic* 

Structured 
Design  [11] 

Based  upon  decomposition 
determined  by  data  flow 
or  data  transformations 

Data  processing  and 
and  algorithmic* 

Jackson 
Method  [12] 

Based  upon  decomposition 
determined  by  data 
structure 

Data  processing 

implementation  determined  primarily  by  algorithm 

that  defined  function  (e.g.  Gauss-Seidel  iterative 
method  for  solving  system  of  linear  equations) 

Figure  3.  Structured  Programming  Methodologies 
(Source  of  Data;  Jensen  [2]) 

a  top-down  fashion  to  analyze  the  requirements  and  formulate 
solution. " [5] 


VALIDATION 

Validation,  or  verification,  confirms  that  a  project/system 
is  reliable  and  meets  its  specifications  as  well  as  the  require¬ 
ments  of  the  user  environment.  Ideally,  an  informal  design  review 
is  held  with  the  tasked  project  group  before  implementation 
begins.  Iterative  reviews  should  continue  throughout  the  project 
life  cycle  up  to  the  delivery  and  operation  phases. 

Additionally,  before  the  design  phase  is  complete,  a  formal 
test  pi  an  for  the  svstem  is  advisable.  This  test  plan  should  be 
ToTntly  agreed  upon  by  the  user  and  design  groups.  Specific 
testing  criteria  and  guidelines  should  be  adopted  for  all  pro¬ 
grams  of  the  system  and  the  testing  should  assure  a  high  measure 
of  rei iabil ity  that  would  be  expected  in  operation  of  computer 
programs.  Furthermore,  a  shakedown  period  is  advisable  after  the 
delivered  software  is  installed. 


SOFTWARE  TOOLS 


A  standard  library  of  specialized  software  tools  should  be 
established.  Software  tools  are  computer  programs  that  automate 
tasks  in  the  management,  production,  and  testing  of  software. 
These  tools  are  usually  inexpensive,  are  often  available  from 
other  users  for  the  cost  of  reproduction,  and  are  often  concise 
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and  easily  modified  for  unique  project  needs.  Some  standard 
tools  are  an  editor,  program  analyzer,  and  program  librarian. 
Text  editors  are  an  excellent  example  of  available  and  useful 
software  tools  that  serve  a  standardized,  special  function  suffi¬ 
ciently  well  and  interface  readily  with  other  tools/programs. 
Program  analyzers  are  software  which  scan  a  source  program  and 
collect  data  about  its  execution  behavior.  Program  librarians 
provide  for  the  storage  and  retrieval  of  different  versions  of 
program  modules 


EVALUATION  METHODS 

Engineering  analysis,  modeling  or  simulation,  and  experience 
data  can  be  used  to  establish  the  performance  needed  in  critical 
software  operations.  Concrete,  measurable  milestones  of  progress 
for  the  desiqn,  programming,  testing,  installation,  and  initial 
operation  of  the  system,  should  also  be  developed  to  ensure  that 
effective  control  of  the  emerging  system  can  be  maintained 
throughout  its  life  cycle. 


WHAT  TYPES  OF  USERS  NEED  SOFTWARE  ENGINEERING? 


The  following  sections  are  intended  to  serve  as  guides  to 
the  users  of  the  different  computer  systems  available  at  DTNSRDC . 

SMALL/ONE-TIME  APPLICATIONS 


Users  with  small  and  one-time  applications,  either  on  a 
strictly  interactive  system  or  on  a  combination  of  interactive 
and  batch,  should  make  use  of  at  least  two  or  three  of  the 
Software  Engineering  techniques  described  above. 


The  first  technique,  documentation,  provide 
permanent  record  of  a  programmer/scientist's  wor 
task  is  later  added  to  and  becomes  a  major  effor 
one-time  application  is  used  more  than  once, 
manent  description  of  the  initial  effort  will  ma 
easier  and  more  time-efficient.  Likewise,  it  i 
someone  not  familiar  with  the  project  read  your 
try  to  follow  the  instructions  provided  for 
format,  input,  etc.  Any  misdirection  discovered 
will  save  later  users  many  hours  of  wasted  effor 


s 

k . 
t, 
A 
ke 
s 


an  invaluable 
Often  a  small 
or  an  intended 
complete,  per- 
the  later  task 
helpful  to  have 


documentation  and 
data  creation  and 
at  this  stage 
t. 


The  second  technique  that  will  be  beneficial  for  small/one- 
time  applications  is  verification.  Often  the  reactions  of  a 
program/system  to  test  data  and  to  real  data  are  radically  dif¬ 
ferent.  Therefore,  it  is  beneficial  to  acquire  and  test  with 
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t 


live  data  before  the  final  turnover  process  is  initiated. 

A  third  useful  technique  is  the  use  of  software  tools,  espe¬ 
cially  text  editors  which  will  save  time  and  effort,  especially 
in  program  modification. 

LARGER  APPLICATIONS 

All  of  the  Software  Engineering  techiques  discussed  earlier 
should  be  used  in  larger  program/systems  with  the  benefits  of 
time  and  cost  efficiency  which  grow  in  proportion  to  the  size  of 
the  project. 

The  benefits  that  small  users  derive  from  documentation  and 
verification  are  even  greater  for  large  programs/systems.  In 
larger  projects,  where  the  project  development  team  concept  is 
employed,  documentation  is  a  shared  on-going  responsibility.  As 
separate  entities  are  joined  and  enhanced,  documentation  can 
serve  as  the  coordinating  factor.  Here  too,  a  final  reading  by  a 
third  party  should  be  included. 

Verification  of  a  large  project  can  be  less  complicated  by 
the  use  of  real  test  data.  Only  in  this  manner  can  the  designers 
be  assured  that  all  program  interfaces  match  and  that  all 
interactions  are  correctly  taking  place.  Correct  interfaces  and 
interactions  can  be  further  ensured  by  strict  control  to  guaran¬ 
tee  uniform  program  alterations  by  programmers. 

In  large  projects,  the  delegation  of  specific  work  assign¬ 
ments  is  made  easier  by  the  Structured  Programming  technique.  The 
use  of  this  technique,  in  which  a  complicated  task  is  subdivided 
into  basic,  assignable  tasks,  makes  the  projects  development 
more  manageable. 

As  in  smaller  projects,  software  tools,  such  as  text  edi¬ 
tors,  can  make  the  program  development  task  easier,  faster,  and 
more  efficient. 


Finally,  a  written  and  formally  agreed  upon  test  plan,  using 
live  data,  helps  ensure  the  success  of  the  project's  development. 
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1 

189.3 

COOPER,  A.  E. 

10 

1892.1 

STRICKLAND,  J.  D. 

1 

1892.2 

SOMMER,  D.  V. 

1 

1892.3 

MINOR,  L.  R. 

1 

1894 

SEALS,  W. 

1 

1896 

GLOVER,  A. 

1 

1896.2 

DENNIS,  L. 

1 

522 

LIBRARY,  CAPDEROCK 

1 

522.2 

LIBRARY,  ANNAPOLIS 

11 
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DTNSRDC  ISSUES  THREE  TYPES  OF  REPORTS 

1.  DTNSRDC  REPORTS.  A  FORMAL  SERIES.  CONTAIN  INFORMATION  OF  PERMANENT  TECH 
NICAL  VALUE.  THEY  CARRY  A  CONSECUTIVE  NUMERICAL  IDENTIFICATION  REGARDLESS  OF 
THEIR  CLASSIFICATION  OR  THE  ORIGINATING  DEPARTMENT. 

2.  DEPARTMENTAL  REPORTS,  A  SEMIFORMAL  SERIES,  CONTAIN  INFORMATION  OF  A  PRELIM 
INARY,  TEMPORARY.  OR  PROPRIETARY  NATURE  OR  OF  LIMITED  INTEREST  OR  SIGNIFICANCE. 
THEY  CARRY  A  DEPARTMENTAL  ALPHANUMERICAL  IDENTIFICATION. 

3.  TECHNICAL  MEMORANDA,  AN  INFORMAL  SERIES,  CONTAIN  TECHNICAL  DOCUMENTATION 
OF  LIMITED  USE  AND  INTEREST.  THEY  ARE  PRIMARILY  WORKING  PAPERS  INTENDED  FOR  IN 
TERNAL  USE.  THEY  CARRY  AN  IDENTIFYING  NUMBER  WHICH  INDICATES  THEIR  TYPE  AND  THE 
NUMERICAL  CODE  OF  THE  ORIGINATING  DEPARTMENT.  ANY  DISTRIBUTION  OUTSIDE  DTNSRDC 
MUST  BE  APPROVED  BY  THE  HEAD  OF  THE  ORIGINATING  DEPARTMENT  ON  A  CASE  BY  CASE 
BASIS. 
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